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(54) System and method for server-host communication connection management and screen 
object management system to serve anticipated future client connections 

(57) A system and method for server-host commu- 
nication connection management allows for reductions 
in lag time experienced by client computers in request- 
ing access to host computers through server computers . 
The system includes a pool of screen objects that are 
available for subsequent use to provide access to the 
host computers for the client computers. The system al- 
so includes a screen pool manager that monitors the 
number of available screen objects and initiates creation 
of additional available screen objects to maintain a suf- 
ficient number to reduce lag time while also enforcing a 
maximum limit of available screen objects to not unduly 
burden resources of the server computers and the host 
computers. In an exemplary embodiment, increment, 
load value, and maximum are used to implement control 
of both minimum and maximum numbers of unused 
screen objects that are available. The communication 
connections are preferrably based on TCP/IP, TN 3270, 
TN 5250 or Telnet. The pool manager preferrably ap- 
plies operations research and queuing theory. 
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Description 

TECHNICAL FIELD 

[0001] The invention relates generally to distributed 
computing environments, and more particularly to a cli- 
ent-server-mainframe environment involving a system 
and method to manage connections between a server 
and mainframe host computer in anticipation of future 
user requests to reduce wait times. 

BACKGROUND OF THE INVENTION 

[0002] Although information technology must deal 
with fast paced advances, it must still deal with legacy 
applications and data that have been inherited from lan- 
guages, platforms, and techniques originated in an ear- 
lier computer era. Most enterprises which use comput- 
ers have legacy applications and databases that contin- 
ue to serve critical business needs. A primary example 
of such legacy applications are found on mainframe host 
computers, such as International Business Machines 
(IBM) model 390 mainframe computers and accessed 
by asynchronous text-based terminals. 
[0003] A large portion of the computer user commu- 
nity no longer use asynchronous text-based terminals, 
but rather use graphical user interface (GUI) based per- 
sonal computers (PCs). Some of these GUI based PCs 
run text-based terminal emulation programs to access 
the mainframe host computers. A disadvantage of the 
text-based terminal emulation programs is that the text- 
based screens furnished are not as user-friendly as a 
GUI based display. To address this and other issues 
some have turned to accessing mainframe host com- 
puters through intermediary server computers. 
[0004] The GUI based PCs form network connections 
with the server computers and in turn the server com- 
puters form network connections with the mainframe 
host computers. Oftentimes these server computers run 
screen scraping programs that translate between lega- 
cy application programs (written to communicate with 
now generally obsolete input/output devices and user 
interfaces) and newer user GUI interfaces so that the 
logic and data associated with the legacy programs can 
continue to be used. Screen scraping is sometimes 
called advanced terminal emulation. 
[0005] For example, a program that does screen 
scraping must take the data coming from the legacy pro- 
gram running on a mainframe host computer that is for- 
matted for the screen of a text-based terminal such as 
an IBM 3270 display or a Digital Equipment Corporation 
VT100 and reformat it for a Microsoft Windows GUI or 
a PC based Web browser. The program must also refor- 
mat user input from the newer user interfaces (such as 
a Windows GUI or a Web browser) so that the request 
can be handled by the legacy application as if it came 
from a user of the older device and user interface. 
[0006] Included with the advances in Information 



Technology have come reductions in time required to 
process and transfer data. Yet, delay time to establish 
a connection between a GUI PC through a server com- 
puter to a mainframe host computer remains problem- 
5 atic. 

SUMMARY OF THE INVENTION 

[0007] The present invention resides in a method and 

10 system for server-host connection management to 
serve anticipated future client connections. Aspects of 
the system and method involve a network communica- 
tively linking a host computer, a server computer, and a 
plurality of client computers. Aspects include a screen 

15 object pool configured to run on the server computer to 
contain available screen objects associated with com- 
munication connections between the server computer 
and the host computer to be available for use by the cli- 
ent computers to access the host computer through the 

20 server computer. 

[0008] Further aspects include a ScreenFactory class 
configured to create the screen objects with the associ- 
ated communication connections between the server 
computer and the host computer to provide access to 

25 the client computers to at least one of data and services 
of the host computer. A screen pool manager is config- 
ured to determine if the number of unused available 
screen objects is below a first number, and if so, the 
screen pool manager is configured to direct the Screen- 

30 Factory class to create a second number of screen ob- 
jects to be added to the unused available screen objects 
in the screen object pool. 

[0009] Additional aspects include the communication 
connections being based upon one or more protocols 
35 selected from a group consisting of TCP/IP, TN3270, 
TN3270E, TN5250, and Telnet. The screen pool man- 
ager is configured to determine the first number and sec- 
ond number based in part upon levels of past requests 
from the client computers for access to the host compu- 
te ter through the server computer. The screen object pool, 
ScreenFactory class, and the screen pool manager are 
configured to run on the server computer. Other aspects 
include the second number being an increment and the 
first number being the product of the increment multi- 
45 p|jed by a load factor. 

[0010] Other features and advantages of the inven- 
tion will become apparent from the following detailed de- 
scription, taken in conjunction with the accompanying 
drawings. 

50 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0011] 

55 Figure 1 is a schematic diagram of a computing sys- 
tem suitable for employing aspects of the present 
invention for secure, duplex browser communica- 
tion. 
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Figure 2 is schematic diagram of a generalized im- 
plementation of the present invention showing plu- 
ralities of client computers, server computers, and 
host computers. 

Figure 3 is a schematic diagram of detail of the 
Screen Factory class associated with embodiments 
of the present invention. 

Figure 4 is a schematic diagram of one of the screen 
pools shown in Figure 3 containing an associated 
screen object. 

DETAILED DESCRIPTION OF THE INVENTION 

[0012] A Server-Host connection management sys- 
tem to serve anticipated future requests by client com- 
puters to host computers through intermediary server 
computers is described. In exemplary embodiments, the 
present invention is directed for use by server based ap- 
plications serving client computers with requirements 
for access to vintage host computers. According to con- 
ventional approaches, as a client computer requests da- 
ta from a host computer through a server computer, a 
connection is made between the server computer and 
the host computer. Any lag time associated with estab- 
lishing a connection between the host and server can 
be an unwelcome consequence to users of the client 
computer. This lag time is generally variable depending 
upon operational conditions existing at the time of the 
request from the client computer. Typical lag times can 
be from 30 milliseconds to 3.5 seconds or longer in du- 
ration. Given user expectations, any delays can be det- 
rimental to user productivity and marketability of soft- 
ware applications. 

[0013] The present invention takes advantage of one 
or more pools of screen objects that have associated 
screen data, screen configurations and communication 
connections to one or more host computers. The 
present invention seeks to maintain a portion of free 
screen objects of each of the one or more pools of 
screen objects. A free screen object has an associated 
server-host communication connection that is idle and 
waiting to service a client computer request for access 
to data on a host computer. As explained further below, 
various procedures can be implemented to balance be- 
tween the objective of having sufficient free screen ob- 
jects available in anticipation of requests by client com- 
puters without overly burdening systems used to estab- 
lish and maintain the server-host communication con- 
nections. In an exemplary embodiment, the present in- 
vention is implemented as a low priority thread to main- 
tain the reductions in lag time secured by the invention. 
[0014] In the following description, numerous specific 
details are provided to provide a thorough understand- 
ing of embodiments of the invention. One skilled in the 
relevant art, however, will recognize that the invention 
can be practiced without one or more of these specific 
details, or with other equivalent elements and compo- 
nents, etc. In other instances, well-known components 



and elements are not shown, or not described in detail, 
to avoid obscuring aspects of the invention or for brevity. 
[0015] Figure 1 and the following discussion provide 
a brief, general description of a suitable computing en- 
5 vironment in which the invention can be implemented. 
Although not required, embodiments of the invention will 
be described in the general context of computer-execut- 
able instructions, such as program application modules, 
objects, or macros being executed by a personal com- 
10 puter. Those skilled in the relevant art will appreciate 
that the invention can be practiced with other computer 
system configurations, including hand-held devices, 
multiprocessor systems, microprocessor-based or pro- 
grammable consumer electronics, network PCs, mini 
computers, mainframe computers, and the like. The in- 
vention can be practiced in distributed computing envi- 
ronments where tasks or modules are performed by re- 
mote processing devices, which are linked through a 
communications network. I n a distributed computing en- 
vironment, program modules may be located in both lo- 
cal and remote memory storage devices. . 
[0016] Referring to Figure 1 , a conventional personal 
computer referred herein as a client computer 10 in- 
cludes a processing unit 12, a system memory 14 and 
a system bus 16 that couples various system compo- 
nents including the system memory to the. processing 
unit. The client computer 1 0 will at times be referred to 
in the singular herein, but this is not intended to limited 
the application of the invention a single client computer 
since in typically embodiments, there will be more than 
one client computer involved. The processing unit 12 
may be any logic processing unit, such as one or more 
central processing units (CPUs), digital signal proces- 
sors (DSPs), application-specific integrated circuits 
(ASIC), etc. Unless described otherwise, the construc- 
tion and operation of the various blocks shown in Figure 
1 are of conventional design. As a result, such blocks 
need not be described in further detail herein, as they 
will be understood by those skilled in the relevant art. 
[001 7] The system bus 1 6 can employ any known bus 
structures or architectures, including a memory bus with 
memory controller, a peripheral bus, and a local bus. 
The system memory 14 includes read-only memory 
("ROM") 18 and random access memory ("RAM") 20. A 
basic input/output system ("BIOS") 22, which can form 
part of the ROM 18, contains basic routines that help 
transfer information between elements within the client 
computer 10, such as during start-up. 
[0018] The client computer 10 also includes a hard 
disk drive 24 for reading from and writing to a hard disk 
25, and an optical disk drive 26 and a magnetic disk 
drive 28 for reading from and writing to removable opti- 
cal disks 30 and magnetic disks 32, respectively. The 
optical disk 30 can be a CD-ROM, while the magnetic 
disk 32 can be a magnetic floppy disk or diskette. The 
hard disk drive 24, optical disk drive 26 and magnetic 
disk drive 28 communicate with the processing unit 12 
via the bus 16. The hard disk drive 24, optical disk drive 
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26 and magnetic disk drive 28 may include interfaces or 
controllers (not shown) coupled between such drives 
and the bus 16, as is known by those skilled in the rel- 
evant art. The drives 24, 26 and 28, and their associated 
computer-readable media, provide nonvolatile storage 
of computer readable instructions, data structures, pro- 
gram modules and other data for the client computer 1 0. 
Although the depicted client computer 1 0 employs hard 
disk 25, optical disk 30 and magnetic disk 32, those 
skilled in the relevant art will appreciate that other types 
of computer-readable media that can store data acces- 
sible by a computer may be employed, such as magnet- 
ic cassettes, flash memory cards, digital video disks 
("DVD"), Bernoulli cartridges, RAMs, ROMs, smart 
cards, etc. 

[001 9] Program modules can be stored in the system 
memory 14, such as an operating system 34, one or 
more application programs 36, other programs or mod- 
ules 38 and program data 40. The system memory 14 
also includes a browser 41 for permitting the client com- 
puter 10 to access and exchange data with sources 
such as web sites of the Internet, corporate intranets, or 
other networks as described below, as well as other 
server applications on server computers such as those 
further discussed below. The browser 41 is markup lan- 
guage based, such as Hypertext Markup Language 
(HTML) and operates with markup languages that use 
syntactically delimited characters added to the data of 
a document to represent the structure of the document. 
[0020] While shown in Figure 1 as being stored in the 
system memory 14, the operating system 34 : applica- 
tion programs 36, other programs/modules 38 : program 
data 40 and browser 41 can be stored on the hard disk 
25 of the hard disk drive 24, the optical disk 30 of the 
optical disk drive 26 and/or the magnetic disk 32 of the 
magnetic disk drive 28. A user can enter commands and 
information into the client computer 1 0 through input de- 
vices such as a keyboard 42 and a pointing device such 
as a mouse 44. Other input devices can include a mi- 
crophone, joystick, game pad, scanner, etc. These and 
other input devices are connected to the processing unit 
1 2 through an interface 46 such as a serial port interface 
that couples to the bus 16, although other interfaces 
such as a parallel port, a game port or a wireless inter- 
face or a universal serial bus ("USB") can be used. A 
monitor 48 or other display device is coupled to the bus 
1 6 via a video interface 50, such as a video adapter. The 
client computer 10 can include other output devices, 
such as speakers, printers, etc. 
[0021] The client computer 10 can operate in a net- 
worked environment using logical connections to one or 
more remote computers, such as a server computer 60. 
The server computer 60 can be another personal com- 
puter, a server, or other type of computer and typically 
includes many or all of the elements described above 
for the client computer 10. The server computer 60 is 
logically connected to one or more of the client comput- 
ers 1 0 under any known method of permitting computers 



to communicate, such as through a local area network 
("LAN") 64 or a wide area network ("WAN") or the Inter- 
net 66. Such networking environments are well known 
in enterprise-wide computer networks, intranets, ext ran - 

5 ets, and the Internet. 

[0022] When used in a LAN networking environment, 
the client computer 10 is connected to the LAN 64 
through an adapter or network interface 68 (communi- 
catively linked to the bus 1 6). When used in a WAN net- 

10 working environment, the client computer 10 often in- 
cludes a modem 70 or other device, such as the network 
interface 68, for establishing communications over the 
WAN/Internet 66. The modem 70 is shown in Figure 1 
as communicatively linked between the interface 46 and 

15 the WAN/Internet 66. In a networked environment, pro- 
gram modules, application programs, or data, or por- 
tions thereof, can be stored in the server computer 60. 
In the depicted embodiment, the client computer 10 is 
communicatively linked to the server computer 60 

20 through the LAN 64 or WAN/Internet 66 with TCP/IP 
middle layer network protocols; however, other similar 
network protocol layers are used in other embodiments. 
Those skilled in the relevant art will readily recognize 
that the network connections shown in Figure 1 are only 

25 some examples of establishing communication links be- 
tween computers, and other links may be used, includ- 
ing wireless links. 

[0023] The server computer 60 is further communica- 
tively linked to a legacy host computer 80 typically 

30 through the LAN 64 or the WAN/internet 66 or other net- 
working configuration such as a direct asynchronous 
connection (not shown). The host computer 80 in an ex- 
emplary embodiment is an international Business Ma- 
chines (IBM) 390 mainframe computer configured to 

35 support IBM 3270 type terminals. Other exemplary em- 
bodiments use other vintage host computers such as 
IBM AS/400 series computers, UNISYS Corporation 
host computers, Digital Equipment Corporation VAX 
host computers and VT/Asynchronous host computers 

40 for the host computer 80. The host computer 80 is con- 
figured to run host applications 82 such as in system 
memory and store host data 84 such as business related 
data. A generalized schematic of an exemplary embod- 
iment is shown in Figure 2 depicting pluralities of the 

45 client computer 1 0, the server 60, and the host computer 
80. 

[0024] An exemplary embodiment is implemented in 
the Sun Microsystems Java programming language to 
take advantage of, among other things, the cross-plat- 
so form capabilities found with the Java language. For in- 
stance, exemplary embodiments include the server 60 
running Windows NT, Win2000, Solaris, and Linux op- 
erating systems. In exemplary embodiments, the server 
60 runs Apache Tomcat/Tomcat Jakarta web server or 
55 Microsoft Internet Internet Information Server (ISS) web 
server, or BEA Weblogic web server. 
[0025] Apache is a freely available Web server that is 
distributed under an "open source" license and runs on 
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most UNIX-based operating systems (such as Linux, 
Solaris, Digital UNIX, and AIX), on other UNIX/POSIX- 
derived systems (such as Rhapsody, BeOs, and 
BS2000/OSD), on AmigaOS, and on Windows NT/ 
95/98. Windows-based systems with Web servers from 
companies such as Microsoft, and Netscape are alter- 
natives, but Apache web server seems suited for enter- 
prises and server locations (such as universities) where 
UNIX-based systems are prevalent. Other embodi- 
ments use other web servers and programming lan- 
guages such as C. C++, and C#. 
[0026] As shown in Figure 3, the depicted embodi- 
ment involves a Java class called Screen Factory class 
90 provided by Attachmate Corporation of Bellevue, WA 
that has a screen pool collection 92 of one or more 
screen pools 94, a screen configuration log 96, and a 
screen pool manager 98. The screen pool collection 92 
affords the opportunity, for instance in an exemplary em- 
bodiment, of having one of the screen pools 94 for each 
one of the host computers 80 involved. The screen pools 
94, as shown by the representative screen pool in Figure 
4, contain one or more screen objects 100 and each 
screen object of a particular screen pool has the same 
configuration. The screen objects 1 00 provide particular 
forms of communication connections between the serv- 
er computer 60 and the host computer 80 and the screen 
pools 94 are particular forms of pools of communication 
connections. Other embodiments utilize other types of 
communication connections and pools of communica- 
tion connections. The configurations of the screen ob- 
jects 100 of a particular one of the screen pools 94 are 
kept in the screen configuration log 96. Other embodi- 
ments used other forms of communication connection 
managers than the screen pool manager 98. 
[0027] In operation, a Java class loader loads the 
ScreenFactory class 90. Since the Screen Factory class 
90 contains the screen pool manger 98, it extends the 
screen pool manager as a thread to be launched and 
run continuously as a background process so that over- 
all performance of the server computer 60 is not detri- 
mentally affected. In one embodiment, when one of the 
client computers 10 initially requests one of the screen 
objects 1 00, the screen pool collection 92 or other com- 
ponents of the ScreenFactory class 90, acting as a com- 
munication connection initiator, creates one of the 
screen pools 94 and creates and associates one of the 
screen objects with the screen pool. As further dis- 
cussed below, the screen pool manager 98 then directs 
the screen pool collection 92 to create additional screen 
objects 100 to be available for future requests by the 
client computers 10. 

[0028] As illustrated in Figure 4, the screen object 1 00 
further contains a session object 104 that contains a 
sub-screen object 1 06 and a connection object 1 08. The 
sub-screen object 1 06 contains detail about the partic- 
ular terminal screen type being used for the session ob- 
ject 104. Such terminal screens include 3270 terminal 
screens, 5250 terminal screens, and other asynchro- 



nous terminal screens. The connection object 1 08 is as- 
sociated with the particular connection being used for 
the session object 104. The screen object 100 also in- 
cludes a screen pool log 110 that contains information 
5 regarding the screen object and its associated screen 
pool 94. 

[0029] The ScreenFactory class 90 is part of a Java 
application programming interface (API) class library 
called Server Enterprise Access Class Library (SEACL) 

to implemented for server environments. SEACL is an API 
that is a set of Java classes and interfaces that allow 
scalable screen scraping applications to be created. 
[0030] The ScreenFactory class 90 provides static 
methods to get and release the screen objects 1 00, pro- 
fs vides IScreen interfaces, and provides requestScreen() 
and release() methods. The IScreen interfaces are con- 
figured to furnish communication connections whenever 
possible between the server computer 60 and the host 
computer 80. The requestScreen() and release() meth- 

20 ods are used to get and release IScreens to allow object 
lifetime to be managed and access to underlying objects 
to be controlled. The ScreenFactory class 90 also im- 
plements an additional management interface that is 
used to gather information about all of the screen ob- 

25 jects 100. 

[0031] The primary methods of the ScreenFactory 
class 90 are IScreen requestScreen(java.lang. String in- 
Name) and Void release(IScreen inScreen, Boolean 
bReset). The former method returns a connected IS- 

30 creen interface and handles all the details of creating 
the underlying objects and interfaces. The latter method 
frees an IScreen interface thereby freeing the underly- 
ing objects and putting them into a ready to reuse state 
or disposes of them. The latter method also sets proxy 

35 IScreens into an "all methods return ScreenReleased 
exception" state. The IScreen interface is a collection of 
Java methods that relies on the screen object 100 to 
handle underlying object creation and configuration to 
present a standard interface to client applications run- 

40 ning on the client computer 10. 

[0032] References to the screen objects 1 00 and da- 
ta, such as business data, are exchanged between the 
screen objects 100 found in the screen pools 94 and 
one or more third party applications 102 (See Figure 3) 

45 such as business logic or integration applications pro- 
vided by application developers, such as programmers, 
consultants, or a company's programmers. In turn, data, 
including screen object references and other data, such 
as business data, is exchanged between the third party 

so application 1 02 and the client computer 1 0 via IScreen 
interface method calls. 

[0033] Data is exchanged between the screen object 
100 of the server computer 60 and the host computer 
80 over the LAN 64 or WAN/Internet 66 using a protocol 
55 appropriate for the host computer. For instance in an ex- 
emplary embodiment, if the host computer 80 is an IBM 
mainframe configured to support IBM 3270 type termi- 
nals, the protocols TCP/IP, TN3270 r and TN3270E, 
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known in the art, are used. For another exemplary em- 
bodiment, if the host computer 80 is an IBM AS/400, the 
protocols TCP/IP and TN5250, known in the art, are 
used. Other protocols such as using standard Telnet fa- 
cilities under the TCP/IP suite of protocols are also used 
as appropriate for communicating with the host compu- 
ter 80. 

[0034] In a conventional approach, the client compu- 
ter 10 requests from the server computer 60, data or 
some other service to be provided by the host computer 
80. The server computer 60 then establishes a commu- 
nication connection with the host computer 80 so that a 
session can occur between the client computer 10 and 
the host computer. Subsequent communication occurs 
between the client computer 10 and the host computer 
80 through the server computer 60 during the session. 
[0035] Under conventional approaches, when the cli- 
ent computer 10 no longer requires the host computer 
10, thereby causing an end to the session, the screen 
object 100 associated with the session is recycled back 
into one of the screen pools 94 of screen objects as an 
available screen object currently not being used, but 
with the communication connection between the server 
computer 60 and the host computer 80 stili being main- 
tained. Under other conventional approaches, once a 
particular session between the client computer 1 0 and 
the host computer 80 through the server computer 60 is 
completed, the associated screen object 100 no longer 
exists. 

[0036] In either of these conventional approaches, 
there is no adjustment mechanism available to specify 
the number of the screen objects 100 that are currently 
available and not being used in one of the screen pools 
94. In one of the conventional approaches, none of the 
screen objects 1 00 remain available after being re- 
leased by the client computer 1 0. In another of the con- 
ventional approaches, the screen object 1 00 is recycled, 
but the number of available screen objects that are not 
currently being used is solely dependent upon a rela- 
tionship between previous demand of screen objects by 
the client computers 1 0 to establish potentially available 
screen objects and the current demand by the client 
computers 10 for the screen objects. Inherent to this 
conventional approach is a frequently occurring situa- 
tion where the screen pool 94 contains for an indefinite 
period of time an inadequate number of available screen 
objects that are not being used with no intervening 
mechanism to signal that more screen objects should 
be created when resources of the server computer 60 
allow for an opportunity to do so. 
[0037] In contrast to conventional approaches, a gen- 
eral objective of the present invention is to allow for a 
sufficient number of available communication connec- 
tions between the server computer 60 and the host com- 
puter 80 that are not being used by one of the client com- 
puters 10 to service additional requests by the client 
computers without having the requesting client comput- 
ers experience lag time associated with establishing a 



communication connection between the server compu- 
ter 60 and the host computer 80. 
[0038] In the context of some of the exemplary em- 
bodiments, this would mean that at any given time there 

5 would be a determined number of the screen objects 
1 00 available, that are not being used, to reduce lag time 
experienced by the client computer 1 0 in communicat- 
ing with the host computer 80. If this determined number 
is too high then resources of the server computer 60 and 

10 the host computer 80 would be overly burdened with es- 
tablishing and maintaining a number of communication 
connections between each other; whereas, if this deter- 
mined number is too low there would be too many in- 
stances when demand by the client computers for com- 

15 munication connections between the server computer 
and the host computer may occur too rapidly to be ad- 
equately serviced. The present invention allows for ad- 
justability of the amount of available communication 
connections (the screen objects 100 in the context of 

20 the exemplary embodiments) between the server com- 
puter 60 and the host computer 80 to better tailor this 
amount to particular configurations and circumstances. 
[0039] In an exemplary embodiment, on a continuous 
basis, the screen pool manager 98 receives pool state 

25 information for each of the screen pools 94 of the screen 
pool collection 92. Based upon this pool state informa- 
tion, the screen pool manager 98 determines if there are 
sufficient numbers of available screen objects 100 in 
each of the screen pools 94 and sends pool manage- 
so ment instructions to the screen pool collection 92 or oth- 
er component of the ScreenFactory class 90 acting as 
the communication connection initiator to increase or re- 
duce the number of available screen objects 100 if the 
determined number of available screen objects is not 

35 sufficient or too large. In other embodiments, screen ob- 
jects are not used, but there still exist one or more pools 
of available communication connections between each 
of the server computers 60 and the host computers 80 
that an equivalent pool manager oversees and provides 

40 pool manager instructions to adjust the number of avail- 
able communication connections when the pool manag- 
er determines that this number is either too large or too 
small. 

[0040] Procedures used by the screen pool manager 
45 98 to determine the number of available screen objects 
1 00 or other equivalent communication connections be- 
tween the servercomputer 60 and the host computer 80 
can involve operations research principles, in general, 
and queueing theory in particular, found, for example, 
so in such works as R Jain, The Art of Computer Systems 
Performance Analysis: Techniques for Experimental 
Design, Measurement, Simulation and Modeling Wiley, 
1 991 ; A O Allen, Introduction to Computer Performance 
Analysis with Mathematica AP Professional, Harcourt 
55 Brace & Co. 1 994; and A O Allen, Probability, Statistics, 
and Queueing Theory with Computer Science Applica- 
tions, Academic Press, 1990. Using these principles, 
the screen pool manager 98 can use data such as his- 
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torical data of previous traffic levels of access requests 
from the client computers 10 of the host computers 80 
to determine and adjust appropriate numbers of availa- 
ble communication connections in a pool between the 
server computers 60 and the host computers 80, in gen- 
eral, and appropriate numbers of available screen ob- 
jects 1 00 in the screen pools 94, in particular, based up- 
on the data and the principles involved. 
[0041] One exemplary embodiment allows for input 
by a user such as an application programmer furnishing 
the third party application 102. Based upon the host 
computer 80, an increment, a load factor and a multiple 
are furnished to the screen pool manager 98. The incre- 
ment and the multiple typically are integer numbers and 
the load factor is typically a fraction between zero and 
one. For instance, the increment may be 10, the load 
factor may be 0.5, and the multiple may be 3. If the 
number of the screen objects 1 00 for a given screen pool 
94 that are available falls below the product of the incre- 
ment and the load factor, in this case 5, the screen pool 
manager 98 directs, through the pool management in- 
structions, the screen pool collection 92 or other com- 
ponents of the ScreenFactory class 90 acting as the 
communication connection initiator to increase the 
number of the screen objects 100 in the screen pool 94 
by the amount of the increment, which in this case is 1 0. 
If the number of the screen objects 100 for a given 
screen pool 94 that are available goes above a maxi- 
mum being the product of the increment and the multi- 
ple, in this case 30, the screen manager 98 directs, 
through the pool management instructions; the screen 
pool collection 92 or other components of the Screen- 
Factory class 90 acting as the communication connec- 
tion initiator to decrease the number of the screen ob- 
jects 100 in the screen pool 94 to the maximum of 30. 
[0042] As an example, with the increment being 10, 
the load factor being 0.5, and the multiple being 3, after 
one of the screen objects 1 00 is initially furnished by the 
ScreenFactory class 90 in response to a first request for 
access to one of the host computers 80 from one of the 
client computers 1 0, the screen pool manager 98 deter- 
mines from pool state information that additional ones 
of the screen objects 100 should be created since the 
initial screen object is furnished to a requesting client 
computer and is, therefore, not an available screen ob- 
ject. The screen pool manager 98 directs the screen 
pool collection 92 or other component of the ScreenFac- 
tory class 90 through the pool management instructions 
to increase the number of the available screen objects 
100 from a present zero to ten, which is the amount of 
the increment. Subsequently, more of the client comput- 
ers 10 request access to one or more of the host com- 
puters 80 through the server computer 60 either rapidly 
or in more of a drawn out fashion until the number of 
screen objects 100 that are available drops below the 
product of the load factor and the increment (in this case 
5). 

[0043] At the point where the number of screen ob- 



jects 100 that are available drops below 5, the screen 
pool manager 98 directs the screen pool collection 92 
or other components of the ScreenFactory class 90 act- 
ing as the communication connection initiator to create 

5 an additional number of the screen objects 1 00 equal to 
the increment, in this case 10, resulting in a total of 14 
screen objects in the screen pool 94. Since the screen 
pool manager 98 is implemented as a low-priority back- 
ground thread, the screen pool manager 98 directs cre- 

10 ation of the additional screen objects 1 00 during times 
when higher priority server operations are not occurring. 
Due to this low-priority status of the screen pool man- 
ager 98, it would be possible that at times under heavy 
demand, the number of available screen objects 100 

15 could fall further below the product of the load factor and 
increment such as to the level of 3 , 2, 1 , or zero available 
screen objects before more screen objects are created 
to be available in the screen object poo! 94. 
[0044] Over the course of operations, the client com- 

20 puters 10 that have requested screen objects 100 will 
be finished communicating with the host computer 80 
and will consequently release the screen objects. As 
part of the ScreenFactory class 90, the screen objects 
100 can be released either as false, in which case the 

25 screen objects and their communication connections 
are terminated, or as true, in which case the screen ob- 
jects and their communication connections remain ac- 
tive as unused connections available for future re- 
quests. For example, a large number of the client com- 

30 puters 1 0 could request the screen objects 1 00 and sub- 
sequently release the screen objects as true resulting 
in more unused screen objects that are available for fu- 
ture use by the client computers than the maximum, 
which is the product of the multiple and the increment 

35 (in this example the maximum is 30). At the point where 
the number of screen objects 100 that are available 
goes above 30, the screen pool manager 98 directs the 
screen pool collection 92 or other components of the 
ScreenFactory class 90 acting as the communication 

40 connection initiator to terminate a number of the screen 
objects 1 00 so that the number of unused screen objects 
100 that are available is equal to the maximum, in this 
case 30. 

[0045] The increment, load factor, and maximum are 
45 adjusted based upon such factors as those related to 
the number of communication connections between the 
server computer 60 and the host computer 80 that can 
be maintained at any one time. Other factors include 
those that are associated with communication connec- 
50 tion time-outs in which a communication connection is 
ended by the host computer after a predetermined 
amount of time has elapsed since any communication 
has occurred between the host computer 80 and the 
server computer 60. In adjusting the increment, load fac- 
55 tor, and maximum, both competing goals of having ad- 
equate reserve of available screen objects 100 and not 
overly burdening resources of the server computer 60 
and the host computer 80 are kept in mind. The incre- 
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ment, load factor, and maximum allow for adjustment of 
both minimum and maximum number of available 
screen objects 1 00 to acceptable levels. In the depicted 
embodiment, Java based static methods are used to 
modify the increment, load factor and maximum applied 
to the screen pool 94 after the screen pool is running. 
Other embodiments focus on other techniques such as 
those provided through operations research and queue- 
ing theory in adjusting minimum and maximum levels 
for available communication connections between the 
server computer 60 and the host computer 80. 
[0046] From the foregoing it will be appreciated that, 
although specific embodiments of the invention have 
been described herein for purposes of illustration, vari- 
ous modifications may be made without deviating from 
the spirit and scope of the invention. Accordingly, the 
invention is not limited except as by the appended 
claims. 



Claims 

1. In a network communicatively linking a host com- 
puter, a server computer, and a plurality of client 
computers, a communication connection manage- 
ment system comprising: 

a communication connection pool configured to 
maintain in addition to communication connec- 
tions through the network between the host 
computer and the server computer being used 
by client computers to access the host compu- 
ter through the server computer, communica- 
tion connections between the host computer 
and the server computer unused but available 
for use by the client computers to access the 
host computer through the server computer; 
a communication connection initiator config- 
ured to create the communication connections 
between the server computer and the host 
computer; and 

a communication connection pool manager 
configured to direct the communication con- 
nection initiator to create a first number of com- 
munication connections to be added to any un- 
used available communication connections in 
the communication connection pool when the 
number of unused available communication 
connections is below a second number. 



figured to request access to the host computer to 
obtain business data and the host computer is con- 
figured to retrieve business data based upon re- 
quests from the client computers. 

5 

4. The communication connection management sys- 
tem of claim 1 wherein the communication connec- 
tion initiator is a Java based ScreenFactory class. 

10 5. The communication connection management sys- 
tem of claim 1 wherein the communication connec- 
tions are associated with Java based screen ob- 
jects. 

15 6. The communication connection management sys- 
tem of claim 1 wherein the communication connec- 
tor pool manager is configured to apply operations 
research and queueing theory with historical traffic 
data of requests from the client computers for ac- 
20 cess to the host computer to determine at least one 
of the first number and the second number. 

7. The communication connection management sys- 
tem of claim 1 wherein the communication connec- 
ts tion pool manager is configured to run as a low-pri- 
ority thread. 

8. The communication connection management sys- 
tem of claim 1 wherein the communication connec- 

30 tion initiator/ the communication connection pool : 
and the communication connection pool manager 
are configured to run on the server computer. 

9. The communication connection management sys- 
35 tern of claim 1 wherein the first number is an incre- 
ment. 

10. The communication connection management sys- 
tem of claim 10 wherein the second number is the 

to product of the first number multiplied by a load fac- 
tor. 

11. The communication connection management sys- 
tem of claim 1 1 wherein the increment is an integer, 

45 and the load factor is greater than zero and less 
than or equal to one. 

12. The communication connection management sys- 
tem of claim 1 wherein the communication connec- 
tion pool manager is further configured to direct the 
communication connection initiator to terminate a 
portion of the unused available communication con- 
nections when the number of unused available 
communication connections in the communication 
connection pool exceeds a third number. 

13. In a network communicatively linking a host com- 
puter, a server computer, and a plurality of client 



2. The communication connection management sys- 
tem of claim 1 wherein the communication connec- 
tions are based upon one or more protocols con- 
sisting of TCP/IP, TN3270, TN3270E, TN5250, and 
Telnet. 55 

3. The communication connection management sys- 
tem of claim 1 wherein the client computers are con- 
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computers, a screen object management system 
comprising: 

a screen object pool configured to run on the 
server computer to contain available screen ob- 
jects associated with communication connec- 
tions between the server computer and the host 
computer to be available for use by the client 
computers to access the host computer 
through the server computer; 
a Screen Factory class configured to create the 
screen objects with the associated communi- 
cation connections between the server compu- 
ter and the host computer to provide access to 
the client computers to at least one of data and 
services of the host computer; and 
a screen pool manager configured to determine 
if the number of unused available screen ob- 
jects is below a first number, and if so, the 
screen pool manager being configured to direct 
the ScreenFactory class to create a second 
number of screen objects to be added to the 
unused available screen objects in the screen 
object pool. 

1 4. The screen object management system of claim 1 3 
wherein the communication connections are based 
upon one or more protocols selected from a group 
consisting of TCP/IP, TN3270, TN5250, and Telnet. 

1 5. The screen object management system of claim 1 3 
wherein the screen pool manager is configured to 
determine the first number and second number 
based in part upon levels of past requests from the 
client computers for access to the host computer 
through the server computer. 

16. The screen object management system of claim 13 
wherein the screen object pool, ScreenFactory 
class, and the screen pool manager arc configured 
to run on the server computer. 

1 7. The screen object management system of claim 1 3 
wherein the second number is an increment. 

1 8. The screen object management system of claim 1 3 
wherein the first number is the product of the incre- 
ment multiplied by a load factor. 

1 9. The screen object management system of claim 1 3 
wherein the increment is an integer, and the load 
factor is greater than zero and less than or equal to 
one. 

20. In a network communicatively connecting a host 
computer, a server computer, and a plurality of cli- 
ent computers, a method for managing communi- 
cation connections comprising: 



maintaining a pool of available communication 
connections between the host computer and 
the server computer to be available for use by 
the client computers that request communica- 
5 tion connections to access the host computer 

through the server computer; 
determining the number of available communi- 
cation connections in the pool available for fu- 
ture requests; 

'0 determining if the number of available commu- 

nication connections in the pool availablefor fu- 
ture requests is at least at a desired amount of 
available communication connections greater 
than zero; and 

15 increasing the number of available communi- 

cation connections in the pool available for fu- 
ture requests if the number of available com- 
munication connections in the pool available for 
future requests is at or below the desired 
20 amount. 

21 . The method of claim 20 wherein the desired amount 
is a first number and the number of available com- 
munication connections are increased by using a 

25 second number as the amount of increase. 

22. The method of claim 21 , further including using op- 
erations research and queueing theory applied to 
historical traffic data of requests from the client 

30 computers for access to the host computer to de- 
termine at least one of the first number and the sec- 
ond number. 

23. The method of claim 21 wherein the number of 
35 available communication connections are in- 
creased using an increment for the second number. 

24. The method of claim 23 wherein the first number for 
the desired amount is a product of the increment 

<o value multiplied by a load factor. 

25. The method of claim 24 wherein the number of 
available communication connections are in- 
creased by the second number using an integer as 

^5 the increment value and the desired amount is de- 
termined with the first number using the load factor 
as being greater than zero and less than or equal 
to one. 

so 26. The method of claim 30, further including decreas- 
ing the number of available communication connec- 
tions in the pool available for future requests if the 
number of available communication connections in 
the pool available for future requests is at or above 
55 a predetermined amount. 

27, In a network communicatively connecting a host 
computer, a server computer, and a plurality of cli- 
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ent computers, a method for managing communi- 
cation connections comprising: 

maintaining a pool of available screen objects 
associated with communication connections 5 
between the host computer and the server 
computers to be available for use by the client 
computers that request communication con- 
nections to access the host computer through 
the server computer; 10 
determining the number of available communi- 
cation connections in the pool available for fu- 
ture requests; 

determining if the number of available screen 
objects in the pool available for future requests 15 
is at least at a desired amount of available 
screen objects greater than zero; and 
increasing the number of available screen ob- 
jects in the pool available for future requests if 
the number of available screen objects in the 20 
pool available for future requests is at or below 
the desired amount. 



28. The method of claim 27 wherein the desired amount 

is a first number and the number of available screen 25 
objects are increased by a second number as the 
amount of the increase. 



29. The method of claim 28, further comprising deter- 
mining at least one of the first number and the sec- 30 
ond number based at least in part upon levels of 
past requests from the client computers for access 

to the host computer through the server computer. 

30. The method of claim 28 wherein the second number 35 
is an increment. 

31 . The method of claim 30 wherein the first number is 
the product of the increment multiplied by a load fac- 
tor. 40 



32. The method of claim 31 wherein the increment is an 
integer and the load factor is greater than zero and 
less than or equal to one. 
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